home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The 640 MEG Shareware Studio 2
/
The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO
/
door
/
csver211.zip
/
HISTORY.CSV
< prev
next >
Wrap
Text File
|
1993-01-10
|
22KB
|
452 lines
History of Changes or Fixes to CSVerify.
Entries are made in reverse order, Newest first;
January 10, 1993 Ver 2.11/M
■ Added support for International phone numbers... I dont knwo if I did
this right, so i'll count on you International SysOps to help me with
that.
January 7, 1993 Ver 2.10/M
■ Added an option in the configuration to allow you to specify the
expiration period of the user. You can leave it blank, or you can
specify any number of days. The default is 365 days (1 year). Putting
730 would equal 2 years and so on.
■ CSV can now be used for CALLBACKS only. If you have a subscription
service that uses callback security, you set the logon security to this
level. When the user logs on, he is immediately taken to CSV, where the
callback phone number is verified. The program will then disconnect the
user, and call him back. After correct password entry, the user is
returned to PCBoard. See the revised DOCS for using this feature.
December 16, 1992 Ver 2.9
■ Corrected a couple of minor details that were being displayed on the
screen.
■ Added support for Fossil Drivers, to maintain compatibility with the
new PCboard 14.5a/M version.
November 12, 1992 Ver 2.8
■ In the interest of protecting the SysOp from doing callbacks that were
long distance that were not mean to be, I tried to use too much logic in
identify a long distance user. I reworked a section of code to make it
much simpler. If you do not allow long distance callbacks, you need to
make sure that the areacode and exchanges for the calling area are
correct in your file. If the program does not find a match from what the
caller enters, the program will flag the caller as long distance, no
matter what he answers to the prompt.
It's as simple as this; If you allow long distance callbacks, set the
parameter in your configuration file, along with the other options for
logging off the user after callback (if desired), and the program will
call the user back. If you say NOTALLOW LD, and the users areacode and
exchange are not in the list, it will consider it long distance, and
deal with it as you have configured. This step shortened the code size,
and makes a lot more sense in program flow.
■ To fall in line with the other doors and the new PCBOARD node numbers
then $$$DUMMY.$$x filename is now $$$DUMMY.node , node being what ever
node created the file. It would look like this;
$$$DUMMY.10 for a file created by node 10.
November 9, 1992 Ver 2.7
■ A slip of the fingers caused this one! In checking a variable to see
if the program was in LOCAL mode, I forgot an equals sign, which caused
the program to switch to local mode, even if it was not really. This
effected the caller, in that once the program switched to local mode,
the caller no longer saw anything sent to the screen. Fixed... Sorry!
November 7, 1992 Ver 2.6
■ A user reported that the program was having trouble opening the
various data files described in configuration file. Turns out that I
specified a length of only 29 characters for each file and pathname for
the trashno.csv file, exchanges.csv etc, and for some that was not
nearly long enough. I increased the length to 40 characters, which
should hopefully clear that problem.
November 2, 1992 Ver 2.5
■ A couple of other minor bugs were reported;
1) - Incorrect number was being placed into the TRASHNO.CSV file if the
user modified it after registration... Fixed!
2) - After a user was updated, and the information screen was displayed,
the incorrect security level and time was being show... Fixed!
3) - The program will sense LOCAL operation now, so if you want to test
the door to see what it does to a record, you can do so. Just a
reminder, if you call the program and pass it a parameter of TEST it
will go through the verification process, but not write any records.
4) - Some cosmetic clean up.
5) - Corrected an error that would cause the areacode to be dialed on a
local number if you were calling out through a PBX system...Fixed!
October 26, 1992 Ver 2.4 **** Change to Configuration File ****
■ Correct a problem that caused every number entered by a user to be
invalid. I was using the wrong variables to see if the areacode or
exchange was a 911, 411, 800, etc. Fixed...
■ Corrected the problem (I think!) with the program not starting the
dialing string with a 1 if the callback was long distance. The program
should now place a 1 and the areacode into the dialing string on all
long distance calls.
■ For users of local metered systems, I added a new line to the
configuration file where you can put the word "METERED". If this is
encountered, as soon as the user has been called back and verified, the
program will display a new file called hangup.csv (which should contain
an explanation on why they have to call the board back), then
disconnect the user. This file will also be displayed if the user is
being called back long distance since they are related.
Pay attention to the changes made in the configuration file so your
program will run properly.
October 19, 1992 Ver 2.3
■ Corrected a bug that was not allowing the program to properly dial
long distance numbers. The program was not getting a switch turned on on
certain cases that would tell it to add the dialing prefix as defined in
your csverify.cnf file. The dialing prefix would include the needed 1
for dialing long distance. On my system I do not have a long distance
carrier assigned to my line, so I can use any carrier by including the
10288 as an example to use AT&T then appending a 1 to that to complete
the dialing prefix. Your dialing string would look something like this;
ATE0M1DT10288-1(555)555-1212.
■ Hardcoded some checks to be sure that some idiot hacker doesn't send
your program dial strings for dialing 900, 800, 911, 411. I put that in
as hardcode for the time being till I think about how the sysOp can have
control over this.... It will check this information just before dialing
and kick them off if the areacode or exchange contains any of these
numbers.
September 8, 1992 Ver 2.2a **** Change to Configuration File ****
■ Made a minor modification to the program to allow the SysOp to
override the newuser security level found in pcboard.dat. This value was
being used by CSVERIFY to determine if a users security level was too
high to use the door. In the configuration file, add line 19, and
SECURITY=## (whatever security level you choose) to override it, or
PCBSECURITY to use the value in pcboard.dat. This allows you to use
other doors to gradually upgrade a user through other doors before the
actual callback verification.
August 15, 1992 Ver 2.2
■ Corrected an logic error which did not take into account incorrectly
entered phone numbers. The program will now look at the phone number
entered, and try to divide it into 3 parts (Areacode, Exchange, and
Number) when the user first enters the door. If unable to split the
number properly, it will then take the user to a screen to enter each
portion of the number separately for proper operation. Since you have
the option of controlling the callback area, the number entered has to
be parsed into its separate sections to be checked.
■ Added a note to the user that the number entered will be the number
called back, so they have an opportunity to change it before the program
does the callback.
August 12, 1992 Ver 2.1
■ Corrected an error which did not write the number to the trash can
file upon successful verification.
■ Working on a parsing routine for the phone numbers to separate them
into area code, exchange, and number when a user enters the phone number
all together without spaces or dashes. Encourage your users to enter the
phone number properly during registration, perhaps displaying a guide
for them by modifying the prompt in PCBTEXT like this;
Business/Data Number XXX XXX-XXXX (800 555-1212)
July 27, 1992 Ver 2.0 *** Major Rewrite ***
■ Version 2 in beta testing... completely rewritten in Turbo C++ 3.0 using
the new PCBoard Door Toolkit from Clark Development.
Setup is not much different than the previous versions. The Phones.dat
file is not longer required, and the config file has changed. Please
refer to the sample config file included in the ZIP for changes.
Please report any problems or suggestions to me on my board. These beta
versions are not for distribution... please do not post them... I will
release the program as FREEWARE as soon as the testing is completed.
June 3, 1992 Ver 1.16 **** Change to Configuration File ****
■ Added the ability for CSVERIFY to call long distance. The change to
the configuration file is this;
On line 13 where it previously had the allowable area code, we now place
a new file, which contains valid area codes that the program can dial.
If you want the program to be able to dial any long distance number,
just create the file with 1 blank line. If you only want the program to
call long distance in certain area codes, then list those area codes in
the new area code.csv file (or whatever you choose to call it), and the
program will only dial numbers in those area codes. If you want to
program to continue as it was prior to this release, simply place your
area code that you allow dialing in, in the first line of the
area code.csv file. The program will then check the valid exchange file
as it always did.
If you allow long distance call backs, you can use the LOGOFF feature to
immediately log the user off after they are verified, and display a
message telling them to call the BBS back on their quarter!
May 16, 1992 Ver 1.15
■ Corrected a problem that was causing a lock-up of the program just
before exiting CSVerify or prior to returning to PCBoard. The program
should be working smoothly now.... (I hope!).
May 8, 1992 Ver 1.14 **** Change to Configuration File ****
■ Added another display file to the program which can be displayed to a
long distance user. You can use the file to give the caller additional
instructions, or tell him what to do next to obtain a higher level or
whatever.
I also corrected some logic where the user once verified was
still able to enter the door with a security level that was too high.
The program will now look at the users security level as soon as the
welcome screen is displayed. If the security level is too high, or the
user was previously verified successfully, it will display the security
file, then return the caller to Pcboard.
April 28, 1992 Ver 1.13
■ Still working on the redial routine, and it looks like I got it this
time. Instead of sending the modem the ATH0 command, I am lowering DTR
then raising it again before I dial the number. It looks like this was
the fix I was looking for. FINALLY FIXED!!!
April 19, 1992 Ver 1.12
■ My battle appears to be consistent with the redial routines. I am
trying different combinations of code for the routine that calls back
the user. Since the program has always worked on my system, I need your
input to let me know whether it's working or not. I have two modems... A
Intel 9600EX and an HST Courier attached to a PS/2 model 60(286),
connected to a Token Ring Lan (Novell 3.11), and I am not using any
fossil drivers or strange TSR's, an the software is working here with no
indication of failure. I am changing version numbers so I can track
which versions have been tried and failed.
April 18, 1992 Ver 1.11
■ Still trying to locate the problem with forcing the modem off hook
during the dial attempt. I made a modification to the program to flush
the com port after the command is sent to it, which will perhaps
facilitate the correct dialing sequence. This program has of course
always worked on my system without a hitch... The trouble may be a slow
response from the modems. I put the code back in to directly send
commands to the com port, as it did not seem to work the other way!
We'll see.
April 10, 1992 Ver 1.10 **** Change to Configuration File ****
■ Added the ability for the SysOp to decide if the user should be
logged off after the callback has been completed. This will help those
users that have calling zones that we would not consider to be long
distance, and even dialed as a local call, but they are charged a fee
for the call. The program will look for the word LOGOFF at line 20 of
the configuration file. If this word *specifically* is found, it will go
through the callback procedure, display the users information, then log
him off with a note to call right back for normal access. In the
meantime PCBoard will update his user record with the updated security
level, and recycle. If the word is anything other than LOGOFF it will be
ignored.
April 10, 1992 Ver 1.09
■ I forgot to add C/R's after the commands sent to the modem, and some
folks had already downloaded the program before I could fix it..
Sorry!
April 9, 1992 Ver 1.08a
■ Trying to tackle a problem with the door locking up on exit with some
systems, I am trying a different approach to closing the door down, and
returning the user back to the BBS. Hopefully this will solve the
problem.
I also got some help on the write fault error that I could not
find, and hopefully got it beat this time!
April 3, 1992 Ver 1.08 **** Change to Configuration File ****
■ In response the John Carroll University's request I added the ability
to be able to call back a caller thru a switch board or PBX. There is a
new parameter in the configuration file called "PBX". If the program
finds PBX=<whatever> it will include that along with the dialing string
sent to the modem during call back. If there is nothing after the equals
sign, it will assume no prefix. The prefix can be 4 characters wide for
special cases.
April 2, 1992 Ver 1.07
■ Still trying to resolve a problem with the dial back routine, a user
is receiving DOS error #5 which is file access denied. In the Lantastic
(or any other network) environment if a file is locked, and you try to
open it again, you get this message. Looking at the dial back routine, I
noticed a couple of logic errors. First, I was assigning the comport,
then resetting it for output, then during the loop, resetting it again
and again. I corrected the problem by closing the comport before
reopening it... hopefully that will clear that problem.
The second error was during the re-dial, after the first attempt.
I was looping back to dial the user again, but the modem was not getting
hung up first, so trying to dial again was for not. Correction was made
by forcing a hang up again before trying to re-dial.
The phones.dat file does not have any record locking on the file, so on
multi-node systems that share the door, you need to create a dummy file
in you batch file, and if another node shows up to use the door, have it
check for the existence of the dummy file, and exit if it's there. I am
trying to find some network file locking routines to prevent conflicts,
but in the mean time, you should work with it this way...
Hey! What do you want for free <g>!
March 28, 1992 Ver 1.06
■ I made a change to the information written back to the users record.
Instead of saying "Bus/Data Number Verified", it now says "### ###-####
was verified, or in the other case NOT verified. This was done so you
would have a record of what number they used, but not alter what was
entered into the User record phone number slots if you choose not to.. I
still provide the verified number in the Bus/Data field of the users
record if you desire..
There was a change made to the name of the $$$DUMMY.$$$ file that is
created if the caller is a long distance number.. I changed the
extension of the file to reflect the node that generated the file. This
way, in multi node operations, one user wont step on another in the door,
and delete his flag file. the file for node 1 as an example would be
$$$DUMMY.$$1 < Thank you Earl Boone for this information!>
You can now pass a pcboard command line parameter to the program called
TEST. If the program receives this parameter, it will not save any
information you type in the trashno.csv or phones.dat files. This
was done so you could test the door, and not have to keep erasing the
datafile or trashno.csv lists every time you try it. If your PCBoard
automatically throws your user into the door, for testing purposes you
can edit the batch file with PCBDOOR=TEST at the top, and PCBDOOR= at
the bottom to reset it.
I corrected some logic errors in the dialback routines, so hopefully
they are working as advertised now.
Please call my board with any requests or problems.... That includes you
Butch .
March 27, 1992 **** Change to Configuration File ***
■ Looking over the logic of the code I made some changes internally
that allow me to better track each step the program takes. I did make
one change externally to the data file, in that I added another field to
the beginning of the record so I could flag a record for deletion. I am
working on this part, so you can edit the user records, and optionally
pack it, removing deleted records. The phones.dat file is a random
access file. I created it this was so look ups and reading and writing
records would be quick... If you have a 1000 records in your data file
sequentially, it could take a while to look at them. The trashno.csv
sample file is still ok, and the numbers contained in it will still get
a hit if you have users records in the data file. Sorry, but I did not
write a conversion program for it. The door has not been out long enough
to warrant this yet. I also filled the remainder of the data record with
filler for future use, so this should be the last time you have to kill
your datafile.
Because a phone number can be in the same area code, and the exchange is
long distance from the BBS, I saw a need to include a file, text in
nature, which includes the various exchanges in your local calling area.
If the program determines that the phone number entered does not meet
the local exchange criteria, it will assume a long distance number has
been entered, and follow accordingly. You can determine you local
calling exchanges by looking in the front few pages of you local
telephone book. It should show the cities that are local calls, and the
exchanges.
March 25, 1992 8:15pm **** Change to Configuration File ***
■ Shortly after putting the code up for download, I installed it just
to test it. Guess what! Murphy's Law struck again. I discovered that the
timing routine that I had just worked on was lacking a line that would
make it act as expected once carrier was detected. I fixed this in this
version... Sorry Butch!
I added another line to the configuration file, and if fact changed the
order that a couple of items were read in. I added a file which you can
call anything you wish, but basically its a trash can file in which
verified phone numbers are placed. It will also allow you the SysOp to
edit this file and put in your own phone numbers which you want
rejected. This time I tested the code before posting it! <g>.
March 25, 1992 **** Change to Configuration File ***
■ Had a report of the program not making a connection to another HST. I
tested this several times without any problem.. is anyone else having
this problem?
The code released on the 23rd was counting down on the re-dial too fast
all the sudden... I don't know what I changed, but it screwed up the
countdown. I reworked the logic on the countdown for dial/re-dial
attempts, and added another line to the configuration file so the SysOp
can define what the timeout should be instead of hard coding it. If the
line is missing from the configuration file, the timeout should default
to 30 seconds. I put the countdown on the screen to watch.
March 23, 1992 **** Change to Configuration File ***
■ Since I added the SYSOP COMMENT on or off, I figured that I should
also make the Bus/Data phone optional too. This way, you can have
written to the users record what you want instead of hard coding it.
I turned off the debug code to see how it goes. Please report any
errors.
March 21, 1992 **** Change to Configuration File ***
■ Made two modifications to the program..
First, you now have the option of turning off the SYSOP COMMENT
from being placed in the users file. Check the Configuration file
for this addition.
Second, For those that want it, if a user answers YES to the long
distance question, the program will now create a dummy file in the
current directory, which allow you to test for existence, and optionally
call another door, like a script door, or whatever. This file
$$DUMMY.$$$ is only created at this time. Your batch file should delete
this file before starting the program with a line that says basically;
if exist $$$DUMMY.$$$ del $$$DUMMY.$$$, then start the door as you
normally would.
March 20, 1992
■ I discovered an error right after I posted the program where the
program would not allow more than one record in the datafile. That was
because I assigned the record number in the wrong place. Fixed...
I have another door that I wrote called Register, which generates the
key files needed for my programs, so I decided that I would make a name
change to this program since no one has downloaded it yet! This program
is now called CSVERIFY (Computer Store Verify).